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□ neither restricted nor paid additional fees. 

2. E9 This Authority found that the requirement of unity of invention is not complied and chose, according to Rule 

68.1 , not to invite the applicant to restrict or pay additional fees. 

3. This Authority considers that the requirement of unity of invention in accordance with Rules 13.1, 13.2 and 13.3 is 

□ complied with. 

JS not complied with for the following reasons: 
see separate sheet 

4. Consequently, the following parts of the international application were the subject of international preliminary 
examination in establishing this report: 

H all parts. 

□ the parts relating to claims Nos. . 

V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial 
applicability; citations and explanations supporting such statement 

1. Statement 



Novelty (N) 
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Claims 


5,11-13,17 




No: 


Claims 


1-4,6-10,14-16 


Inventive step (IS) 


Yes: 


Claims 


12,13 




No: 


Claims 


1-11,14-17 


Industrial applicability (IA) 


Yes: 


Claims 


1-17 




No: 


Claims 





2. Citations and explanations 
see separate sheet 

VII. Certain defects in the international application 

The following defects in the form or contents of the international application have been noted: 
see separate sheet 
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VIII. Certain observations on the international application 

The following observations on the clarity of the claims, description, and drawings or on the question whether the 
claims are fully supported by the description, are made: 

see separate sheet 
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Re Item I 

Basis of the report 

1. Claims 14 and 15 on page 33 are indicated in the report as 16 and 17, respectively. 
Re Item IV 

Lack of unity of invention 

1 . Claims 1, 14, 15 and 16 are based on the concept of inducing users to accommodate 
their bandwidth requirements in a shared network. This is achieved by automatically 
varying a tariff for network usage by a customer terminal depending on the network 
loading. 

2. Claim 13 is based on the concept of avoiding uncertainty about the price for a 
network usage. This is achieved by applying to customer terminals a tariff for network 
usage, varying the tariff with time; at a customer terminal, selecting a period of time 
for which the tariff is to be fixed; and paying a premium depending on the duration 
of said period. 

3. Thus, the two above-mentioned claim groups are based on different concepts and 
comprise different technical features. 



Re Item V 

Reasoned statement under Article 35(2) with regard to novelty, inventive step or 
industrial applicability; citations and explanations supporting such statement 

Reference is made to the following documents: 

D1: MURPHY J ET AL: 'DISTRIBUTED PRICING FOR EMBEDDED ATM 
NETWORKS 1 FUNDAMENTAL ROLE OF TELETRAFFIC IN THE EVOLUTION 
OF TELECOMMUNICATION NETWORKS, PROCEEDINGS OF THE 14TH. 
INTERNATIONAL TELETRAFFIC CONGRESS - ITC 1 JUAN-LEES-PINS, 
JUNE 6 - 10, 1994, no. 1B, 6 June 1994, pages 1053-1063, LABETOULLE J; 
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ROBERTS J W (EDS) ISBN: 0-444-82031-0 

D2: SIETMANN R: TARIFMODELLE GEGEN STAUS AUF DER INFOBAHN' 
FUNKSCHAU, vol. 71, no. 8, 3 April 1998, pages 28-30. 

D3: ESTRIN D ET AL: •DESIGN CONSIDERATIONS FOR USAGE ACCOUNTING 
AND FEEDBACK IN INTERNETWORKS 1 COMPUTER COMMUNICATIONS 
REVIEW, vol. 20, no. 5, 1 October 1990, pages 56-66, ISSN: 0146-4833 

D4: MURPHY L ET AL: 'FEEDBACK AND EFFICIENCY IN ATM NETWORKS' 
1996 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS (ICC), 
CONVERGING TECHNOLOGIES FOR TOMORROW'S APPLICATIONS 
DALLAS, JUNE 23 - 27, 1996, vol. 2, 23 June 1996, pages 1045-1049, 
INSTITUTE OF ELECTRICAL & ELECTRONICS ENGINEERS 



1 . Claim 1 does not meet the requirement of novelty, Article 33(2) PCT. 

1.1. Document D1 discloses a method of operating a communications network, including 
automatically varying at a customer terminal, depending on the network loading as 
detected at a customer terminal, a tariff for network usage by the customer terminal 
(see, e.g. page 1054, lines 17 to 33; page 1061, lines 33 to 42; Figure 2). 

1 .2 It is to be noted that the feature of automatically varying a tariff at a customer terminal 
is implicitly disclosed in D1, page 1061, lines 29-42, where the users alter their 
valuation of bandwidth depending on their service requirements and the quality of 
service provided by the network. Therefore, the customer terminal varies the price 
to pay for a determined bandwidth according to the network loading. 

2. The following documents also disclose all the features of claim 1: 

Document D2 (see, e.g. pages 29-30, Section 'Dynamischer Preis fur virtuelle 
Verbindungen'); 

Document D3 (see, e.g. pages 61-62, Section 3.2.4; page 61, section 3.2.2, first 
paragraph; page 65, section 4.8, last paragraph); 

Document D4 (see, e.g. pages 1046-1047, section 3.1; page 1047, section 4.1.2). 
Therefore, claim 1 also lacks novelty vis-a-vis these documents. 
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3. The objections above (see points 1 and 2) also apply to independent claims 14, 15 
and 16 which comprise the corresponding features to claim 1, in terms of a 
communications network and a customer terminal. 

4. The additional features of the dependent claims 2-1 1 and 17 do not add anything 
new or inventive to the independent claims because these features are either known 
from the above prior art (detecting at the customer terminal a network performance 
parameter; making tariff increases; programming a decision agent; distributing a tariff 
algorithm via the communications network to a plurality of terminals; using the 
number of packets lost as the network performance parameter; detecting a 
congestion signal at the customer terminal; generating a congestion signal at a 
router; intermittently sampling traffic between a customer terminal and the network, 
recording network loading affecting the customer terminal) or are common measures 
(reading a congestion signal at the customer terminal from a data packet received; 
returning a congestion notification signal to the data source by the customer terminal 
when it detects congestion; varying the tariff only if the terminal fails to reduce its 
output in response to detected congestion). 

5. Claim 13 relates to a method of operating a communications network, applying to 
customer terminals a tariff for its use. This tariff varies with time. Such a method is 
well-known and it is disclosed, for example, in D1 (see, e.g. page 1054, lines 17-33) 
and also in D2, D3 and D4. 

5.1 The problem solved by the invention of claim 13 is avoiding uncertainty about the 
price for a network usage. 

5.2 This problem is solved by selecting, at a customer terminal, a period of time for which 
the tariff is to be fixed, and paying a premium depending on the duration of this 
period. 

5.3 Although fixing a tariff for a period of time is considered common knowledge, the 
features of selecting the period by the user and paying a premium depending on its 
duration are not disclosed in or suggested by the prior art and, therefore, involve an 
inventive step. 
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Documents D1 , D2, D3 and D4 describe methods of inducing the users to adapt their 
bandwidth requirements to the load of the network by varying the tariff for the network 
usage but none of them mention any possibility for the user to fix the tariff for a period 
of time. 



Re Item VII 

Certain defects in the international application 

1 . The independent claims are not in the two-part form as required by Rule 6.3(b) PCT, 
and the features already disclosed in document D1 are not placed in the preamble. 

2. Reference signs in parentheses have not been inserted in the claims to increase their 
intelligibility (Rule 6.2(b) PCT). This applies to both the preamble and characterising 
portion. 

3. The documents D1, D2, D3 and D4 have not been identified in the description and 
their relevant contents are not briefly indicated, Rule 5.1(a)(ii) PCT. 

Re Item VIII 

Certain observations on the international application 

1 . To meet the requirement of conciseness, Article 6 PCT, a single claim should have 
been filed in each category (method and apparatus). 

2. The terms ' relatively smaller increase' and ' relatively larger increase' in claim 7 are 
vague and imprecise and render the scope of the claims unclear (Guidelines, C-lll 
4.5). 
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31 
CLAIMS 



1 . A method of operating a communications network, including automatically varying 
at a customer terminal, depending on network loading as detected at the customer 
terminal, a tariff for network usage by the customer terminal. 

2. A method according to claim 1, including detecting at the customer terminal a 
network performance parameter which depends on network loading, and varying the 
tariff depending on the network performance parameter. 

3 A method according to claim 2, in which the network is a packet network and 
the network performance parameter is the number of packets lost in transmission 
between a data source and the customer terminal. 

4. A method according to claim 1 , including detecting a congestion signal at the 
customer terminal and varying the tariff in response to the congestion signal. 



5. A method according to - claim 4, including reading a congestion signal at the 
customer terminal from a data packet received at the customer terminal. 

6. A method according to claim 4 or 5, including generating a congestion signal at a 
router in the network in response to the detection of congestion at the router. 

7. A method according to any one of the preceding claims, including making a first 
25 relatively smaller increase in the tariff when congestion is first detected, and making 

at least one further, relatively larger increase, if the congestion persists 

8. A method according to any one of the preceding claims, including programming a 
decision agent at the customer terminal with user-determined price criteria, and 

30 comparing a price calculated using the tariff with the said price criteria. 

9- A method according to any one of the preceding claims, including distributing a 
tariff algorithm via the communications network to a plurality of terminals and 
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calculating at each terminal, using the tariff a oh*™ * 

My tne xariTT, a charge for network usage by the 

terminal. 



10. A method according to claim 9 further n*™** • 

a », runner comprising steps, carried out by the 

5 network operator, of: 

intermittently sampling traffic between a customer terminal and the network 
and as part of the samp.ing recording network loading affecting the customer 
terminal; and 

for the sampled traffic comparing a charge ca.cu.ated by the customer 
1 0 termma. and an expected charge and detecting thereby any discrepancy. 

11. A method according to any one of the preceding Cairn,, in which when the 
customer termina. detects congestion in data transmitted to the customer terminal 
from a data source via the network, the customer termina. returns a congestion 

1 o notification signal to the data source. 

12. A method according to any one of the preceding claims, including at a customer 
termmal, selecting a period of time for which the tariff is to be fixed and paying a 
premium depending on the duration of the said period. 

13. A method of operating a communications network including applying to 
customer termina.s a tariff for network usage, varying the tariff with time; at a 
customer terminal, selecting a period of time for which the tariff is to be fixed; and 
paying a premium depending on the duration of the said period. 

14. A communications network including : 
means for detecting network loading locally at a customer terminal; and 
means responsive to the said means for detecting arranged automatically to 

vary a tariff for network usage by the customer terminal. 

15. A customer terminal for use in a communist;™* 

uummunications network, the customer 

terminal including: 
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means for detecting loading of a network to which, in use, the customer 

terminal is connected; 

means responsive to the said means for detecting and arranged automatically 
to vary a tariff for network usage by the customer terminal. 

5 

14. A customer terminal for use in a communications network, the customer 
terminal including one or more processors arranged to carry out the following 
steps in sequence: 

detecting loading of resources in a network to which the customer terminal is 
10 connected; and 

automatically varying in dependence on the detected loading a tariff for 
network usage by the customer terminal. 

15. A method according to any one of claims 1 to 1 3, in which the tariff is 
15 varied only if the terminal fails to reduce its output in response to detected 

congestion. 
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Communications Network 

BACKGROUND TO THE INVENTION 

The present invention relates to a communications network, and in particular 
to charging mechanisms in such a network. It includes aspects of the inventions 
disclosed and claimed in the present applicant's co-pending British patent application 
no. 9812161.9 filed 5 June 1998 (applicant's ref: A25547) and the contents of that 
earlier application are incorporated herein by reference. 

in conventional communications networks, such as national PSTNs (public 
switched telephone networks), a significant proportion of the network resources are 
devoted to metering and billing network usage. Studies have estimated these 
resources as consuming as much as 6% of the revenue of a telecommunications 
company. The Internet, by contrast, does not in general incorporate metering and 
billing mechanisms for individual customers. The absence of the network 
infrastructure required to support metering and billing reduces the operational costs 
of the Internet compared to conventional telephony networks, and has facilitated the 
rapid expansion of the Internet. However, the absence of appropriate billing 
mechanisms has significant disadvantages in terms of the characteristics of the 
traffic carried by the Internet: it encourages profligate use of network resources, and 
diminishes the incentive for investment in network infrastructure to support new 
applications requiring, e.g., guaranteed quality of service (QoS). 

SUMMARY OF THE INVENTION 

According to a first aspect of the present invention, there is provided a 
method of operating a communications network, including automatically varying, 
depending on network loading as detected at a customer terminal, a tariff for 
network usage by the customer terminal. 

In this document references to varying a tariff encompass changing a price, 
e.g. as a function of a congestion parameter. The structure of the tariff may be 
unchanged. 

The present invention provides an approach to charging for network usage 
which involves little or no network overheads, and which moreover is able to reflect 
local variations in network loading. This is achieved by detecting a measure of 
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network loading at the customer terminal. This measure will reflect those resources 
being used by the customer terminal at a particular time. For example, in a federated 
data network comprising a number of sub-domains, such as the Internet, a customer 
terminal in one subdomain may attempt to access a server in another subdomain at a 
time when there is overloading of a router somewhere in the path from the customer 
terminal to the server. Then, even if average loading of the network as a whole is 
low, the loading as perceived by the customer terminal is high, and a tariff for use of 
the network by the customer terminal is increased to reflect the scarcity of the 
relevant network resources. Similarly other terminals attempting to access data via 
the same router will also perceive the network loading as being high, and will also 
have their tariffs increased accordingly. With an appropriately steep rise in tariff, at 
least some customer terminals will then choose to abandon or defer their attempts to 
use the network resource in question, thereby relieving the loading of the router. 

This aspect of the invention may be used in systems in which the end user is 
merely informed of the price and accounting and billing is carried out by the network 
provider, also in systems where the end user measures their usage and supplies this 
information to the network provider, and also in systems where the end user both 
measures their usage and calculates the payment due to the network provider. 

The method may include detecting at the customer terminal a network 
performance parameter which depends on network loading, and varying the tariff 
depending on the network performance parameter. When the network is a packet 
network, then the network performance parameter may be the number of packets 
lost in transmission between a data source and the customer terminal. This approach 
has the advantage that it is suitable for implementation using existing congestion 
control mechanisms in packet networks. For example, in the Internet, routers 
respond to congestion by dropping packets, and a customer terminal using TCP 
(Transport Control Protocol) detects packet loss and controls a congestion window at 
the terminal accordingly. The present invention may use the detected packet loss to 
trigger an increase in the tariff applicable to the terminal. This may be accompanied 
by the signalling of congestion by the receiving terminal to the data source. 

In an alternative and preferred approach, when congestion is detected within 
the network an explicit congestion signal may be generated and transmitted to the 
customer terminal, and the receipt of the explicit congestion signal at the customer 
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terminal may then trigger the increase in the tariff. This approach has the advantage 
that an appropriate congestion signal may be generated in advance of significant 
degradation in network performance occurring, making it easier to maintain a required 
quality of service. Preferably the explicit congestion signal is carried with a data 
5 packet on the communications network. Preferably a router in the network writes on 
explicit congestion signal in a packet when congestion is detected at the router. 

As a further alternative, the congestion notification signal may be a source 
quench signal generated at the router and transmitted back to the data source. 

Preferably there is a non-linear relationship between the increase in tariff and 

10 the detected network loading. Preferably the method includes making a first relatively 
smaller increase in the tariff when congestion is first detected, and making at least 
one further, relatively larger increase, if the congestion persists. This behaviour may 
be pre-programmed into the tariff algorithm. In this way oscillatory behaviour of the 
network can be avoided, while ensuring that a sufficient increase is made to have a 

15 desired impact on the demand for network resources. 

Preferably the method includes programming a decision agent at the 
customer terminal with user-determined price criteria, and comparing a price 
calculated using the tariff with the said price criteria. For example, the decision 
agent might be programmed to proceed with data communications as long as a per- 

20 packet charge is zero or is less than a predetermined threshold. Then if congestion 
causes the charge to rise above that threshold, the data communication is interrupted 
and the decision agent modifies the operation of the customer terminal. For example 
the decision agent may slow down communications once the cost threshold is 
exceeded. The user may then choose to continue with the communication, or may 

25 elect to abandon the attempt to access data from a particular source. The decision 
agent may be programmed with rules which relate to an overall price for multiple 
simultaneous transmissions and which accord different weights to different 
respective applications. 

Preferably the method includes distributing a tariff algorithm via the 

30 communications network to a plurality of terminals and calculating at each terminal 
using the tariff a charge for network usage by the terminal. In this case preferably 
the method includes steps, carried out by a network operator, of intermittently 
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sampling traffic between a customer terminal and the network, and as part of the 
sampling recording network loading affecting the customer terminal; 

for the sampled traffic comparing a charge calculated by the customer 
terminal and an expected charge and detecting thereby any discrepancy. 
5 The step of recording network loading may involve, for example, recording 

packet drops, or explicit congestion notification (ECN) bits or source quench 
messages. 

The invention also encompasses a network operating by a method in 
accordance with the first aspect of the invention, and customer terminals, network 
10 routers and other network nodes for use in such a network. 



DESCRIPTION OF DRAWINGS 

Systems embodying the present invention will now be described in further 
detail, by way of example only, with reference to the accompanying drawings, in 
15 which: 

Figure 1 is a schematic showing a network embodying the invention; 
Figures 2a and 2b are graphs showing tariff functions; 
Figure 3 shows the format of a differential service byte; 

Figure 4 is a schematic showing the component objects of a charging 
20 architecture for use with the network of Figure 1; 

Figure 5 shows data passed between the accounting objects of Figure 4; 
Figure 6 is a schematic showing protocol stacks on a customer terminal and 
in the network domain; 

Figure 7 is a graph showing the variation of tariff with time; 
25 Figures 8a to 8e are class diagrams for software implementing accounting 

and measurement objects; 

Figure 9 is a diagram showing a graphic user interface (GUI) for use with the 
objects of figures 8a to 8e; 

Figure 10 is a class diagram for software implementing tariff objects; and 
30 Figure 1 1 is a diagram showing an alternative embodiment. 



DESCRIPTION OF EXAMPLES 
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As shown in Figure 1, a communications network 1 includes a number of 
network sub-domains 2A-C. The network sub-domains may be under the control of 
different operators who may not trust each other. The network subdomains are 
interconnected by gateway routers 3, 4. In the present example the communications 
network is the Internet and supports both unicast and multicast Internet Protocol CP) 
and associated protocols. A customer terminal 5 is connected via a public switched 
telephony network (PSTN) 6 and an access router 7 to a subdomain 2A. A single 
blocking test is applied to traffic at this point of access. The gateway routers 3,4, 
and access router 7 may be commercially available devices such as CISCO series 
7500 routers and CISCO series AS5800 universal access server respectively. Other 
customer terminals are connected to the network, including a Java-enabled mobile 
terminal 8 and a data server 9. The customer terminal 5 may be connected via a 
LAN to an accounting server. The accounting server may include an accounting 
object as described below that receives measurement data from the customer 
terminal. 

In addition to the local tariff variation mechanism that is described below, 
the network also uses network-based control of a number of tariff bands. A 
network management platform 10 is connected to each subdomain. Each network 
management platform may comprise, for example, a computing system comprising a 
SPARC workstation running UNIX (Solaris) together with network management 
applications. The network management platform 10 hosts management entities and 
tariff entities. The network management platform communicates with agents 100 in 
managed devices connected to the respective subdomain, for example using SNMP 
(simple network management protocol). The management platforms monitors the 
overall loading of network resources in the respective subdomains, and, as will be 
further described below, adjust the tariffs for network use accordingly. The Net 
management platform (NMP) instructs the agent to monitor the device and report 
aggregated results at regular intervals back to the NMP, so the NMP can monitor the 
combination of all reports. 

Tariff data is communicated to peer tariff entities in other subdomains and 
also to the customer terminals. The tariff data is multicast using, for example 
Distance Vector Multicast Routing Protocol (DVMRP) or Protocol Independent 
Multicast (PIM) dense mode. The tariff data channels are announced and monitored 
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using protocols based on SDP (Session Description Protocol), SAP (Session 
Announcement Protocol) Charging is carried out on a "pay and display" model. Each 
customer terminal monitors its own network usage, for example by counting the 
number of packets it sends or receives across the network interface and the quantity 
of data (in bytes) in those packets. It calculates, using a tariff received via the 
network, the payment due to the network operator, and makes a corresponding 
payment into an account >at the network operator. The network operator polices the 
use made by customers of the terminal by intermittently sampling traffic to or from a 
particular customer and comparing the use made and the use paid for. 

The tariffs supplied to the customer terminals are divided into bands of 
different volatilities. The tariffs are varied under the control of the network operators 
to reflect the overall loading of the network. That is to say, if network loading 
becomes high, then the tariffs may be increased to reflect the scarcity of network 
resources. 

A service provider may offer different products defined by different service 
level agreements, and/or by different price volatilities. For example product A might 
offer best-effort service at a fixed price while another product B might offer best- 
effort service at a variable price. A service provider may adjust product prices on the 
basis of the following parameters: the price the service provider pays to its wholesale 
provider: competitors' prices; current resource utilisation; relevant demand for 
different products. In response to changes in these parameters, tariff adjustments 
may be effected in one of three ways. Firstly, a tariff may adjust prices on the basis 
of local observations of network loading, without necessitating explicit 
communication from the provider. This approach, which is described in further detail 
below, needs to be built into the tariff at the outset, and is limited to those price 
variations which are dependent exclusively on local observations. Secondly, the 
provider may tune a tariff by adjusting some of its parameters. This kind of 
adjustment is required when the decision is dependent on parameters which cannot 
be observed directly by the customer, e.g., variation in the wholesale price of 
network resources. Thirdly, the provider may completely replace a tariff. This is 
required when the existing tariff cannot accommodate the changes that are required. 

The first of the tariff changes described above is necessarily carried out 
automatically. The second type of change may be performed manually, or by an 
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agent that issues adjustments automatically in response to observations made by the 
service provider system. The third type of change is likely to be performed manually, 
as replacement of a new tariff will in general require an element of design requiring 
human input. However, it is possible that an agent might be employed to 
5 automatically switch tariffs for a product on the basis of a set of specified rules. 

This section describes a prototype that we implemented to demonstrate the tariff 
subsystem outlined above. Features of the design include: 

• using mobile code to represent tariffs and associated user interface components; 

• use of a repeated multicast announcement protocol to communicate tariffs and 
10 tariff adjustments efficiently; 

• using dynamic class loading and reflection in order to receive and tune tariffs. 
The prototype consists of a library of general-purpose Java classes and two specific 
applications, namely: 

• a provider system which allows the provider to introduce, replace, and tune tariffs 
15 for a number of products; 

• a customer system that enables customer to keep track of the charges being 
applied for the products they are using. 

The provider system services multiple instances of the customer system running on 
different hosts in a multicast-enabled network. A multicast announcement protocol is 
20 used to communicate tariff changes from the provider system to customer systems. 
In order to maximise flexibility with respect to the definition of tariffs, we chose to 
represent tariffs using Java classes. This technique is also used to supply user 
interface components to customers to support visualisation of the behaviour of a 
tariff. 

25 The Tariff interface acts as the base class for all tariffs. This defines a 

single operation get GUI () which returns as a Java SWING component that can be 
incorporated into the customers GUI (graphical user interface). This GUI component 
enables the customer to visualise the behaviour of the tariff using techniques 
appropriate to the tariff. 

30 Subclasses of the Tarrif interface establish a set of tariff types, each of 

which is associated with a different set of measurement and input parameters. 
These parameters are identified by listing them in the signature of the getCharge 
() method. For example, the interface RSVPTariff defines getCharge ( ) as 
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receiving n RSVP TSPEC, allowing for the definition of tariffs that compute price on 
the basis of the characteristics of an RSVP reservation. On the other hand, the 
interface PacketCountTarif f defines getCharge ( ) as receiving measurements of 
packets in, packets out, and current congestion (typically measured as a function of 
5 packet drop), allowing for the definition of tariffs that are dependent on packet 
counts and sensitive to congestion. Other tariffs may be added as new forms of 
usage-measurement emerge. 

Tariffs are defined by providing implementations of the various tariff 
interfaces described above. For example, the tariff PacketCountLinear implements 
10 PacketCountTarif f to compute charges in proportion to packet counts. Another 
tariff CongestionSensitiveLinear works on a similar basis, but adds a penalty 
charge if the customer does not stay within a specified traffic limit in the presence of 
congestion. 

In addition to the tariff interface implementation, a tariff may make use of 
15 other 'helper' classes to assist in its operation, as well as one or more user interface 
component classes for customer visualisation purposes. A provider-side user 
interface may also be required in order to enable the provider to make tariff 
adjustments. 

A complete tariff description consists of a set of Java classes, some of 
20 which are destined for the customer system and others which are intended for use by 
the provider system The customer-side classes are bundled into a Java archive 
(JAR) file to facilitate processing by the provider system. 

In order to deploy a new tariff, the provider system first loads the tariff 
classes which it requires into its execution environment. It then loads the customer- 
25 side bundle, serialises it, signs it with a private key, and uses an announcement 
protocol to distribute it to customer systems. The use of a signature makes it 
possible for customers to verify that received tariffs are authentic. 

Upon receiving the bundle, each customer system verifies the signature 
(using the public key matching the provider's private key), and at the activation time 
30 specified in the announcement protocol headers which may be significantly later, e.g. 
hours or days, unpacks the bundle, and loads the classes into its execution 
environment using a purpose-built dynamic class loader. An instance of the received 
tariff class is created and installed in place of the previous tariff. If the tariff has a 
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user interface component (obtained by calling the tariff object's getGUI () method), 
then it replaces the user interface of the previous tariff. The change in user interface 
serves to notify the user that the tariff has changed. 

Tariff adjustment involves the remote invocation of an operation which is 
specific to the tariff currently in force. This means that a customer system cannot 
know the signature of this operation in advance of receiving the tariff i.e. the 
operation will not be listed in any of the tariff interfaces known to the customer 
system. 

In order to get around this problem, use is made of the "reflection" feature 
supported by Java. In order to disseminate a tariff adjustment, the provider creates 
an instance of an Invocation object, which stores the name of the operation to be 
called, together with the parameters that are to be supplied to it. This object is then 
serialised, signed, and announced using the announcement protocol. When an 
adjustment is receive and verified by a customer system, the Invocation object is 
de-serialised and applied to the current tariff by using reflection to invoke the 
described operation. 

In order to simplify the announcement protocol, adjustments are required to 
be idempotent and complete. Idempotency guarantees that a tariff will not be 
adversely affected if an adjustment is applied more than once. Completeness implies 
that an adjustment determines the entire parameter set of a tariff object, so that an 
adjustment completely removed the effects of any previously applied adjustments. 

The customer system may apply a tariff by repeatedly invoking the 
getCharge () operation supported by that tariff every second, and adding the 
returned value to the cumulative charge. The parameters supplied to getCharge 
() depend on the kind of tariff currently in force. For example, if the tariff is an 
implementation of PacketCountTarif f , then measurements of inbound packets, 
outbound packets and congestion over the past second are required. However, if the 
tariff is an implementation of RsvpTarif f , then only a TSPEC describing the current 
reservation is required. This implies that a customer system can only subscribe to a 
product if it can supply the parameters require by the tariff associated with hat 
product. 
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Each invocation of the getCharge {) method also results in an update to the 
tariff-specific user interface. For example, in the CongestionSensitiveLinear 
tariff, the usage parameters supplied to getCharge () are used to update the 
graphical displays of traffic and congestion. 
5 The announcement protocol is used to communicate serialised tariffs and 

adjustments from a provider system to multiple customer systems. The number of 
customer systems is assumed to be large, and a repeated multicast solution is 
adopted. 

Each product supported by a provider is assigned a multicast channel for 

10 announcement purposes. Customer systems listen to the channels corresponding to 
the products that they are using. In the current implementation, it is assumed that 
each customer system has knowledge of well-known multicast addresses for the 
products it is interested in. 

For each product channel, the provider repeatedly announces the current 

15 tariff and the most recent adjustment made to it (if any). Each announcement carries 
a version number, which is incremented each time the announcement is changed. 
Customer systems only process announcements when a version number change is 
detected. If a new customer joins a channel, it waits until it receives a tariff before 
processing any adjustment announcements. Furthermore, an adjustment is only 

20 applied if its announcement version is greater than that of the current tariff, thereby 
ensuring that a missed tariff announcement does not result in the application of a 
subsequent adjustment to an old tariff. 

While centralised monitoring and control of tariffs by the network 
management platform is effective to respond to global changes in the loading of the 

25 network, it is difficult to handle localised congestion in this way. It is difficult to 
cause a price rise signal to be multicast in such a way that the signal is only received 
by those attempting to communicate packets through the point of congestion. This 
would require a separate multicast transmission for each element in the internet , e.g. 
a multicast for every different queue on every interface of every router. Alternatively 

30 some aggregation of price rises triggered by local resource loading might be used. 
This however would mean that price rise signals were sent to users who were not 
making use of the congested resource. This in turn would make it necessary tor the 
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price rise signal to be damped, reducing the ability of the price rise to reduce the 
demand on the congested resource. 

To overcome these difficulties, the tariff algorithms installed on the customer 
terminals are arranged to respond automatically to congestion in a network resource 
5 being used by the terminal. Each algorithm includes a function which varies the price 
for network usage in dependence upon the detected congestion level. This function 
may be integrated in the main tariff algorithm, or, as in the example described here 
may be a separate algorithm used to calculate a premium to be added to a price 
calculated in accordance with the main tariff algorithm. 

10 The main tariff algorithm calculates a price P as a function of a number of 

quality parameters, Q 1; Q 2 , Q 3 where, for example, is a specified latency for 
packets communicated across the interface between the customer terminal and the 
network, Q 2 is the reserved bandwidth for the transmission, Q 3 is a specified level of 
reliability corresponding to a maximum permissible level of packet loss. 

1 5 The price P is then given by: 

P = f(Q„ Q 2 , Q 3 ) 

An example of the pricing function in terms of one of the quality parameters Q is 
shown schematically in Figure 2a. 

The congestion tariff algorithm calculates a premium AP which is a function 
20 of one or more congestion parameters C: 

AP = f(C 1 , C 2 ...) 

The congestion parameters provide a measure of the loading of the resources which a 
customer terminal is making use of at any given time. In the present example the 
ratio of packets lost to packets received is used as the congestion parameter. This 

25 parameter is readily calculated, for example in the case of packets using TCP 
(transport control protocol), or RTP (real time protocol) over UDP (user datagram 
protocol), since such packets include a sequence number. Figure 2b shows one 
example of the function for generating the premium. In this case, the premium 
increases as an approximately exponential function of the congestion, so that at low 

30 congestion levels a small premium is charged, while if congestion increases still 
further, then at higher levels of congestion the premium increases sharply. 

In an alternative implementation, an explicit congestion signal is added by 
any congested router within the network to packets transmitted to the customer 
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terminal. Whether congestion is signalled explicitly or implicitly by packet drop, the 
price algorithm might not directly charge for congestion indication. Instead, it may 
charge if the customer terminal does not halve the congestion window in response to 
a congestion indication. Halving the congestion window halves the rate of 
5 transmission which is the standard response to congestion indication used in TCP and 
other compatible congestion control protocols. The change in transmission rate can 
be measured by the network provider as well as at the customer terminal, although 
this places a heavy load on router processing resources. If the provider is merely 
sampling certain customers to audit their own measurements, this results in an 

10 acceptable load. 

Although only a single main tariff and premium are described here, in practice 
different subdomains, and different service providers associated with each 
subdomain, may each have a different pricing structure, with different main and 
premium tariffs. However, there is across all the subdomains a common relationship 

15 between network loading levels and congestion signalling. 

The operation of this second implementation will now be described in the 
context of a network operating using a differentiated service as described in the 
Internet Engineering Task Force draft "Differentiated Services Operational Model and 
Definitions" and in the paper by David D Clark (MIT), "A Model for Cost Allocation 

20 and Pricing in the Internet", presented at MIT Workshop on Internet Economics, Mar 
1995, URL:http://www. press. umich.edu/jep/works/ClarkModel.html. In a network 
implementing differentiated services, nodes are arranged to discriminate between 
packets to provide different levels of service. This capability might be used, for 
example, to accord delay-sensitive data, such as data generated by an IP telephony 

25 client, a higher priority compared to other data, such as email data. At the network 
edge, for example at a client terminal running the IP telephony client, bits in a TOS 
(type of service) octet contained within each packet header are set to indicate the 
appropriate service level. Those bits are used by routers within the network to 
determine how the relevant packets should be handled. 

30 The TOS octet when used in this way is termed the DS (differential service) 

byte. The format of the differential service byte is shown in Figure 3. Bit zero, 
labelled "IN" indicates whether the packet is inside or outside a defined profile. Bits 
1 to 5 labelled "PHB" define a "per-hop-behaviour" that is they indicate how, for 
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example, a router should handle the packet, e.g. by according it lower or higher 
priority. Bits 6 to 7, in this particular form of the DS byte, are used for explicit 
congestion notification (ECN). One of these bits is set to indicate whether the 
routers in the path of the packet are capable of setting the ECN field, and the other 
5 bit is used as a flag which is set (by ECN capable routers) when congestion, or 
loading which would potentially lead to congestion, occurs. Random Early Detection 
(RED) algorithms are currently implemented in routers. These algorithms measure 
average queue length within the packet buffers of a router. An exponential moving 
average is calculated. When that average queue length exceeds a predetermined 

10 threshold, then the router signals that congestion is occurring. Conventionally this 
signalling has been done simply by dropping a packet. However, in the context of an 
ECN scheme, the router, instead of dropping a packet, sets an ECN bit in a packet 
header to indicate that congestion is occurring. This is done probabilistically: that is, 
some only of the packets passing through the router are marked. The probability of 

15 a packet being marked increases with the average queue size. In the rare case that 
the queue increases to a length where the router buffers are full, then packets are 
dropped, rather than an ECN bit being set. In this case ECN bits are set for all the 
remaining packets. 

In operation, if the client terminal 5 is accessing a data source on the server 
20 9, congestion may occur, for example, at router 4 which links network sub-domains 
2B and 2C. RED-like algorithms in the router 4 detect that the queue lengths in the 
router buffers, as calculated using the exponential moving average, exceed a 
predetermined threshold. Accordingly some of the packets from the server 9 en 
route to the client terminal have the ECN bit of the DS byte set by the router 9 to 
25 mark the fact that congestion is occurring. At the client terminal, the DS byte in the 
headers of incoming packets is read. A moving average of the number of packets 
containing an ECN bit which is marked is calculated. This average then provides the 
congestion parameter C , which is used to calculate the premium: 

AP =f(CJ. 

30 The total price to the user P T0T is then calculated by adding together the prices 
determined by main tariff algorithm and by the premium algorithm: 
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This total price is passed to a cost decision agent running on the client terminal. This 
cost decision agent is programmed with user defined rules. These might state, for 
example, that the cost decision agent should authorise the system to proceed with a 
connection as long as the total cost averaged over a certain time period falls below a 
5 predetermined threshold, e.g. of £0.01 per minute, and that the cost decision agent 
should suspend a connection and alert the user if the cost rises above that threshold. 
Alternatively, as previously noted, the cost decision agent may handle several 
applications simultaneously, and may be programmed to slow down one of the 
applications as the premium for using a data source accessed by that application 
10 increases. 

For some customers in some circumstances, the variability of the tariff for 
network usage may pose problems. For example, a customer might wish to schedule 
a multicast audio-video conference with, say, twenty participants and with the 
customer intending to pay the network usage costs for all of the participants. The 

15 conference will be scheduled a day or more in advance, but since the tariff is variable 
over time, at the point when the conference is scheduled, the customer will not know 
the cost which will be incurred. The preferred implementation of the present 
invention overcomes this problem for the customer, and also provides an additional 
revenue source for the network operator. This is achieved by applying a further tariff 

20 which defines a premium for price stability for a given customer terminal, the value of 
the premium increasing as the required duration of the period of stability increases. 
In the example referred to above, the customer scheduling a conference one day in 
advance refers to the current tariff to determine the present cost of the network 
resources required, including any congestion premium currently applicable, and then 

25 refers to the further tariff to determine the premium for maintaining the cost at its 
present value for a period of one day. Then if the user decides to make use of the 
fixed tariff a message is sent from the user to the network operator. The message 
identifies the data flows in question, for example by specifying the IP addresses and 
the service levels for the audio and video data flows between the participants, 

30 together with the current time at which the user is contracting for a fixed period, and 
the required duration of the fixed period and also an identifying code for the message. 
Alternatively, the message with these details may be tracked with an appropriate 
cryptographic function (e.g. MD5), and the hash value only communicated initially to 
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the provider, and subsequently used to verify account data. Subsequently, for the 
duration of the specified period, in this case one day, the user applies the fixed tariff. 
In systems where the users themselves are responsible for generating accounting 
data and calculating the applicable charge for network usage, then the user calculates 
5 the charge using the fixed tariff and returns the accounting data to the network 
operator together with the identifying code for the fixed tariff contract. 

This aspect of the invention is not only applicable to systems where tariff 
variation is carried out locally in response to the detection of congestion, but may 
also be used in systems where, for example, the only variation is imposed by the 
10 network operator. 

The tariff for the stability premium may be distributed by multicasting from 
tariff entities in network operator platforms to the customer terminals in the same 
manner as described previously for the other tariffs discussed above. As with those 
other tariffs, different tariffs and optionally different periods of stability might apply 
15 to different service levels. In a scenario such as that discussed in the preceding 
paragraph, then different service levels might be used for different elements of the 
audio and video data streams required for the multicast conference. 

Figure 2c shows a possible for the stability premium tariff. This tariff may be 
embodied in a Java function multicast to the users. Curve C is communicated to the 
20 customer terminal as another subsidiary algorithm that contributes to the main tariff 
algorithm. The customer may choose a period of price stability and calculate the 
premium above the spot price that his will require using curve C. Curve B is an 
example of the stable price chosen in a particular case. Once the period of stability 
expires a new one can be bought at the premium over the spot price at that time. To 
25 buy a period of price stability, the customer must announce the period required and 
the range of addresses for which it applies to her provider. It may be required for one 
address (e.g. for the duration of an Internet phone call to a single person) or for a 
range of addresses (e.g. for a video conference). Certain risk-averse customers might 
request stable pricing for all addresses all the time. 
30 For ease of description, the preceding sections have treated in isolation the 

local variations in tariff in response to congestion. In practice, this mechanism will in 
general be combined with other responses to congestion, and with other sources of 
variation in the tariff. Also, a decision to proceed with a transmission despite 
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congestion will in general require the consent of parties at both ends of the 
transmission. Considering the entire system of the data source, network and routers 
and the data receiver, the implementation of an increase in tariff (also termed here a 
"fine") in response to locally detected congestion occurs as a last resort; Other 
5 responses are implemented first, in the following numerical order: 
1 .the network re-routes around congestion 

2. the network borrows capacity from lower levels of service (lower in the context of 

the relevant dimension(s) of QoS) including the best effort service 

3. the network introduces extra capacity (possibly automatically) 

10 4.the end-system establishes that the congestion is on the shared network and not 
just on the access links or end systems 

5. the end-system sets QoS requirements to a "higher" level (if cheaper than the fine 
for ignoring congestion at the current level) 

6. the end-system decides it is essential to ignore the congestion, given the fine for 
15 doing 

so might be quite high 

7. both (all) end-systems agree to ignore the congestion. 

Typically, it is at step 4 that an ECN signal is generated. Steps 1 to 3 
precede the generation of this signal and steps 5 to 7 follow the generation of the 
20 ECN signal. 

The last step prior to proceeding with a connection and paying the premium 
for doing so is establishing agreement by both parties. Accordingly, when the 
customer terminal detects congestion, either through receiving explicit congestion 
notification, or through detection of a relevant parameter such as packet loss, the 

25 customer terminal signals this fact back to the or each other end system. In the 
present example therefore, the client terminal 5 signals to the data server 9 that 
congestion is occurring. The data server is programmed with rules, which as at the 
customer may be implemented as an agent, which determine the response to such a 
signal. For example, the server may refuse service in these conditions. As 

30 described previously with respect to Figure 1, in the present example tariffs are 
multicast through the network from network operators to the customer terminals, and 
charging is carried out using a "pay and display" process. Figures 4a and 4b shows 
the objects used to implement the charging architecture in this case. Figure 4a 
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shows the higher level objects and 4b shows the component objects used in a 
software implementation of the architecture of Figure 4b. In Figure 4a, objects on 
the client terminal are shown in the half of the Figure labelled "customer" and objects 
on the access router 7 and the corresponding network sub-domain are shown in the 
5 half of the Figure labelled "edge network". The objects on the customer terminal 
include a session control object S, a customer business rules object B c , a customer 
pricing object Pr c/ a QoS manager Q, a customer accounting object Act c and a 
customer measurement object M c . The business rules object B c receives information 
on those aspects of the session which involve liability for payment and receives 
10 current pricing data from the pricing object Pr c . The customer business object makes 
decisions, under the customer's policy control on which chargeable services are 
utilised, and how much of the chargeable services are utilised. These decisions are 
fed to the QoS manager Q, which decides which mechanisms are used to achieve the 
requirements. The QoS manager then controls the customer measurement object M c 
15 to determine which aspects of traffic and service to measure and which aspects to 
ignore. The measurement object then records the selected aspects of the traffic, for 
example counting the number of packets received by the customer terminal and the 
QoS levels for those packets. These data together with the current tariffs, including 
any premium for congestion, are then used by the customer terminal to determine the 
20 charge payable to the network operator. The measurement object M c is also 
programmed with instructions which determine the frequency with which it passes 
data to the customer accounting object Act c . The customer accounting object Act c 
passes payments to an accounting object Act p in the network provider's domain. 

The accounting objects on the customer terminal may be implemented using 
25 a small encrypted flat-file database. On the network provider's side, the equivalent 
objects may be implemented using a larger database that is scaleable to handle e.g., 
tens of thousands of customer accounts. An object request broker (ORB) is used for 
communication between the customer-side objects and the network-side objects, 
implemented using commercially available tools such as ORBIX (TradeMark) from lona 
30 Technologies pic. 

On the network provider's side, that is to say within the subdomain to which 
the customer terminal is connected, the customer's traffic is measured by a version 
of M, denoted M p , but only on a sampling basis determined by the policing function, 
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Po. That is to say, the network operator samples the customer's traffic only 
intermittently. Po controls where in the network measurements are made in order to 
capture all of any particular customer's traffic. A bulk measurement function, M b/ is 
responsible for reporting aggregate traffic levels, as reflected in the moving average 
5 of the router queue lengths, to the pricing object Pr p . Bulk measurements would 
typically be collected from across the provider's domain to a centralised pricing 
function (which would be replicated for reliability). Pr p sets prices taking into account 
the business rules from the network provider's business object, B p , as well as the 
current traffic levels reported by Mb and pricing from neighbouring providers (see 

10 below). The policing function, Po, compares sample measurements from M p with 
accounting messages received at Act p as a result of the customers own 
measurements . If it establishes that the accounts are insufficient it might restrict 
service at the access control gateway, Acs, or initiate some other punishment. 
Encapsulated within the accounting object another policing object checks the 

15 accounts match the payments within the contracted time for payment. Finally, the 
identity mapping function, I, provides a mapping between a customer's identity 
(account, digital signature, etc.) and their current network address (typically allocated 
by the ISP, whether unicast or multicast). 

Figure 5 shows the data which are passed between the accounting objects. 

20 In this example the account data comprises: account identity; bill record identity; 
service type identifier; source address; destination address; tariff identity; time; 
period (i.e. the period covered by the bill record); units; cost; and currency. In 
addition, the payment data comprises the amount of money and the currency of 
payment. 

25 Figure 6 shows the measurement region within protocol stacks on the 

customer terminal and in the network domain. Ideally there would be two 
measurement points within this region, one trusted by the customer and one trusted 
by the network, for example at the two points referenced (a) in the Figure. For ease 
of implementation, a single measurement point (b) trusted by both parties may be 

30 used. This might be implemented, for example within a secure module such as a 
cryptographic card on the client terminal. As an alternative, measurements may be 
made at different points with some possibility of discrepancies between 
measurements. On the network the practical measurement point is at the first 
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access device(s) that, for each customer, inspects network layer headers (c)(IP in this 
case). ISPs should not measure any deeper into their network (d) because their 
access network and systems will introduce delays and losses. 

For an individual customer (e.g. on dial-up access), a practical point at which 
5 to measure would also be alongside the network layer but in their end-system's stack 
(e). Ideally these measurement points would be lower in each stack to be closer 
to the interface between the two parties and less likely to be affected by contention 
in the stack. However, measuring at the link layer (f-f) would be inappropriate 
because only some chargeable parameters set at the network layer will ever be 

10 reflected in link layer frames; network level multicast, end-end latency requirements 
etc. may never be visible at the link layer. Also, link layer headers would need to be 
ignored when measuring packet sizes for bandwidth calculations to avoid apparent 
discrepancies where different link technologies are chained together. 

In the reception direction (up the stack) this choice of measurement points 

15 implies that the lower layers must be dimensioned (buffer sizes, interrupt and thread 
scheduling priorities) to cope with the most stringent QoS requirements of higher 
layers. As frames are taken off the physical media, the machine must be able to pass 
data up the stack without any chance that usage-charged data gets discarded (e.g. 
due to buffer overflow caused by interrupt contention) before it gets to the network 

20 layer. It is at the network layer where the ISP's service is to be measured and where 
it is most convenient for QoS requirements to control correct differential treatment of 
the various flows as they are passed further up the stack (on end-systems) or 
forwarded (on routers). 

The measurement objects described above may be implemented using, with 

25 appropriate modifications, publicly available network metering software such as Nevil 
Brownlee's NeTraMet system. This is a software meter which conforms to the IETF 
internet accounting architecture described in RFC 2063 and RFC 2064. The meter 
builds up, using "packet sniffing", packet and byte counts for traffic flows, which are 
defined by their end-point addresses. Although generally, Addresses can be ethernet 

30 addresses, protocol addresses (IP, DECnet, EtherTalk, IPX or CLNS) or 'transport 1 
addresses (IP port numbers, etc), or any combination of these, in the present 
implementation IP addresses only are used. The traffic flows to be observed are 
specified by a set of rules, which are downloaded to NeTraMet by a 'manager 1 
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program. Traffic flow data is collected via SNMP (Simple Network Management 
Protocol) from a 'collector' program. 

Figure 7 shows how the main tariff determined by the network operator 
varies in time. In the Figure, curve A is the spot price calculated to reflect the 
5 loading of the network at any instant. Curve B is one of a number of different tariff 
bands. Different tariff bands have different volatilities, and the customer pays a 
premium for bands offering greater stability. Tariffs are communicated to the 
customer terminals using a hierarchy of channels carried by the network. An initial 
contract between a customer and a service provider a single channel address that 

10 might typically hold new announcements distributed some months apart (e.g. for 
contract variations or for new services specifying which second level channel to 
listen to for tariffs or for downloading new code to handle new tariff structures). The 
second level channels might deliver updates hours apart which simply announce the 
addresses of third level channels for the most volatile information. These third level 

15 channels may carry updates at intervals of less than a second. Prices for many 
services may be carried on one channel. For greatest efficiency, this one channel 
may be split into several channels at times of highest volatility, and re-aggregated 
into a single channel in more stable periods. 

Tables 1 to 7 below list Java source code used to implement two different 

20 tariffs. The code of table 1 establishes the operations used for communication 
between a customer system and a tariff algorithm downloaded by the customer 
system. Table 2 shows a linear tariff algorithm, in which the tariff depends on the 
total of the packets sent and packets received by the customer together with a 
congestion parameter. Table 3 shows the code for generating the customer display 

25 in this case. Table 4 shows the code used to display the tariff at the network 
operator's server. Table 5 shows an exponential tariff algorithm. Table 6 generates 
the customer display and Table 7 the operator display for the exponential tariff 
algorithm. By downloading Java code to generate the user interface, that interface 
can be tailored to the requirements of the particular tariff, and can be adapted as the 

30 tariff changes. 

Although the examples so far described have been in the context of 
federated packet data networks, such as the Internet, many aspects of the invention 
can also be used with advantage in other types of network, such as in a circuit- 
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switched PSTN (public switched telephony network). Figure 1 1 shows an example of 
the invention applied in this context. In this network, customer terminals 81, which 
are in this example so-called intelligent phones, that is telephones incorporating a 
microprocessor and a data interface, are connected via local exchanges 82 and trunk 
5 exchanges 3 to the telephony networks. The trunk exchanges 83 are connected via 
a common channel SS7 (signalling system number 7) signalling network to a service 
control point 85 that is responsible for the execution of advanced call control 
functions. The service control point 85 is also connected to an operational support 
server 86 that is responsible for billing operations, and that, in this example, controls 

10 the setting of tariffs for the network. The OSS server and customer terminals include 
tariff entities (TE). The fixed PSTN network is also interconnected via a gateway 87 
to a cellular GSM network 88. Base Stations BS in the cellular network communicate 
signals to intelligent mobile phones 89. In operation, network tariffs are distributed 
to customer terminals via the PSTN network and via the GSM network. 

15 Conveniently, the tariff may again take the form of Java functions which are 
executed on processors in the customer terminals. The Java functions may be 
streamed as Internet packets, in one implementation, these Internet packets may be 
distributed via the PSTN networks and GSM networks themselves. For example, the 
packets may be encapsulated and transported to the trunk exchanges using the MTP 

20 (message transport part) transport layer and may be communicated onwards to the 
customer terminals using out-of-band signalling. Alternatively, a separate data 
connection may be established between the OSS server and the customer terminals 
via the public internet. As in the examples above, the network operator monitors the 
loading of resources within the network and may transmit signals to the tariff entities 

25 in the customer terminals to change the tariff to reflect the scarceness or otherwise 
of relevant resources. Customer terminals may themselves monitor network loading 
and automatically generate variations in the tariffs. Usage of network resources may 
be measured locally by the customer terminals instead of conventional billing carried 
out within the network. The network operator may police the measurement of usage 

30 data by carrying out sampling, as described previously. 
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Table 1 

// Generated by Together 

package com. bt.jungle.lsma. charging. pricing; 

import com. sun.java. swing, JComponent; 

/**This establishes the operations used for 

communication between the customer system 

and the downloaded algorithm. 

@author Mike Rizzo*/ 

public interface Tariff { 

Jcomponenet getGUK ); 

Float getPrice (int pkin, int pkout, int cng); 
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Table 2 

package algorithms. linear; 

5 import com. sunjava. swing. JComponent; 

import com. sun.java. swing. JTextField; 

import com.bt.jungle.lsma. charging. pricing,Tariff ; 

10 public class LinearAlgorithm implements Tariff { 

private float rate; 

private LinearAlgorithnDisplay display; 
public LinearAlgorithm ( ) { 

display = new LinearAlgorithmDisplay ( ); 
15 setRate (new Float(D); 

} 

public float getPrice (int pkin, int pkout, int cng) { 
return (pkin + pkout + cng) * rate; 

} 

20 public JComponent getGUK } { return display; } 

public void setRate (Float f) { 
rate = f .floatValuel ) ; 
display. setRate (rate) ; 

} 

25 } 
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Table 3 

// Generated by Together 

package algorithms. linear; 

import com. sun. java.s wing. JPanel; 
import com. sun.java. swing. JTextField; 
import com. sun.java. swing. Box; 
import com. sun. java.s wing. JLabel; 

public class LinearAlgorithmDisplay extends Jpanel { 

private JTextField tfRate = new JTextField (4); 
public LinearAlgorithmDisplay ( ) { 

Box vbox = Box.createVerticalBox ( ) ; 

Box hbox = Box.createHorizontalBox ( ) ; 
hbox.add (Box.createHorizontalGlue ( )) ; 
hbox. add (new Jlabel ("Rate:")); 
hbox.add (Box.createHorizontalGlue( )); 
hbox.add (tfRate); 
tfRate. setEditable (false); 
hbox.add (Box.createHorizontalGlue( )) 
vbox. add (hbox); 

add (vboxO); 

} 

public void setRate (float f) { 

tfRate.setText (String.valueOf (f)); 

} 
} 
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Table 4 



// Generated by Together 
package algorithms. linear; 

5 

import com. sun.java. swing.*; 
import java.awt.event.*; 

import com. bt.jungle.lsma. charging. pricing. provider. *; 
10 import com.bt.jungle.util.*; 

public class LinearAlgorithmGUI extends Jpanel { 

private JTextField tfRate - new JTextField ( ); 
private TuningMessageListener tuningMessageListener; 
15 private final static String DEFAULTRATE = "1.0"; 

public LinearAlgorithmGUI (TuningMessageListener tml) { 
tuningMessageListener = tml; 
tfRate. setText (DEFAULT RATE); 

20 Box vbox = Box.createVerticalBox( ); 

Box hbox = Box.createHorizontalBox ( ); 
hbox.add (new Jlabel ("Rate:")); 
hbox. add (Box.createHorizontaiGlue( )); 
25 hbox.add (tfRate); 

hbox.add (Box.createHorizontalGluef )); 
hbox.add (hbox); 

JButton bTransmit = new JButton ("Transmit"); 
30 bTransmit. addActionListener ( 

new ActionListener ( ) { 

public void actionPerformed (ActionEvent e) { 
transmit ( ) ; 

} 

35 } 

); 

hbox = Box.createHorizontaIBox( ); 
hbox.add. (Box.createHorizontalGlue( )); 
hbox.add (bTransmit); 
40 hbox.add (Box.createHorizontalGlue( )); 

vbox. add (hbox); 

add (vbox); 

} 

45 void transmit ( ) { 

try { 

Float f = new Float (tf Rate.getText( )); 
Object args [ ] = new Object [1]; 
Args [0] = f; 

50 TuningMessageListener. notifyf 
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new Invocation ("SetRate", args) 

); 

} 

catch (Exception e) { 

e.printStackTrace ( ); 

} 

} 

} 
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Table 5 

package algorithms. exp; 

5 import com. sun.java. swing. JComponent; 

import com. sun.java. swing. JTextField; 

import com. sun.java. Isma. charging. pricing. Tariff; 

10 public class ExpAlgorithm implements tariff { 

private float min; 
private float base; 
private float divisor; 
private ExpAlgorithmDisplay display( ); 
15 public ExpAlgorithm( ) { 

display = new ExpAlgorithmDisplay ( ); 

setMin (new Float (1)); 

setBase (new Float (2)); 

setDivisor (new Float (10)); 

20 } 

public float getPrice (int pkin, int pkout, int cng) { 

return min + (float)math.pow (base, (pkin 4-pkout + cng)/divisor); 

} 

public JComponent getGUK ) {return display; } 
25 public void setMin (Float f) { 

min = f .floatValuef ); 
display. setMin(min); 

} 

public void setBase (Float f) { 
30 base = f .floatValue( ); 

display. setBase(base); 

} 

public void set Divisor (Float f) { 
base = f .floatValue( ); 
35 display. setBase (divisor); 

} 

} 
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Table 6 

// Generated by Together 

5 package algorithms. exp; 

import java.awt.GridLayout; 
import com. sun. java. swing JPanel; 
import com. sun.java. swing JTextField; 
10 import com. sun.java. swing. Box; 

import com. sun.java. swing. JLabel; 

public class ExpAigorithmDisplay extends Jpanel { 
private JLabel tfDisplay = new JLabel ( ); 
1 5 private float min, base, div; 

public ExpAigorithmDisplay ( ) { 

add (tfDisplay); 

20 // tfDisplay.setEditable (false); 

updateDisplay ( ); 

} 

private void updateDisplay ( ) { 

tfDisplay. setText ("price = " + min + " + " + base + 
25 ""{(pkin + pkout + cng)/" + div +")"); 
} 

public void setMin (float f) { 
min = f; 

updateDisplay ( ); 

30 } 

public void setBase (float f ) { 
base = f; 
updateDisplay ( ); 

35 public void setDivisor (float f) { 

div = f; 

updateDisplay { ); 

} 



WO 99/65185 



PCT/GB99/01773 



10 



29 

Table 7 

// Generated by Together 

package algorithms. exp; 

import java.awt.GridLayout; 
import com. sun.java. swing.*; 
import java. awt. event. *; 

import com. bt.jungleJsma. charging. pricing. provider. *; 
import com. bt Jungle. util.*; 



public class ExpAigorithmGUi extends Jpanel { 
15 private JTextField tfMin = new JTextField ( ); 

private JTextField tfBase = new JtextFfield ( ); 
private JTextField tf Divisor = new JTextField ( ); 

private TuningMessageListener tuningMessageListener; 
20 private final static String DEFAULT MIN = "1.0"; 

private final static String DEFAULTBASE = "2.0"; 
private final static String DEFAULTDIV = "10.0"; 

public ExpAigorithmGUi (TuningMessageListener tml) { 
25 tuningMessageListener = tml; 

tfMin. setText (DEFAULT MIN); 
tfBase. setText (DEFAULT BASE); 
tf Divisor. setText (DEFAULTDIV); 

30 Box vbox = Box.createVerticalBox ( ); 

vbox.add (new JLabel ("price = min + pow (base, 
(pkin + pkout + cng)/divisor)")); 

35 vbox.add (Box.createVerticalGlue ( )); 

Jpanet panel = new JPanel (new GridLayout (3,2)); 
panel. add (new JLabel ("Minimum")); 
panel. add (tfMin); 
40 tfMin. addActionListener ( 

new ActionListener ( ) { 

public void actionPerformed (ActionEvent e) { 
transmit ("setMin", tfMin); 

} 

45 } 

}; 

panel. add (new JLabel ("Base")); 
panel. add (tfBase) 
tfBase. addActionListener ( 
50 new ActionListener ( ) { 
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public void actionPerformed (ActionEvent e) { 
transmit ("setBase", tfBase); 

} 

} 

5 }; 

panel. add (new JLabel ("Divisor")); 
panel. add (tfDivisor); 
tfDivisor.addActionListener ( 
new ActionListner ( ) { 
10 public void actionPerformed (ActionEvent e) { 

transmit ("setDivisor", tfDivisor); 

} 

} 

); 

15 vbox.add (panel); 

add (vbox) 

} 

void transmit (String m, JTextField tf) { 
20 try { 

Float f = new Float (tf.getText ( )); 
Object args [ ] = new Object [1]; 
args [0] = f; 

tuningMessageListener. notify! 
25 new Invocation (m, args) 

); 

} 

catch (Exception e) { 
e.printStackTrace ( ); 
30 } 
} 
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CLAIMS 

1 . A method of operating a communications network, including automatically 
varying, depending on network loading as detected at a customer terminal, a tariff for 

5 network usage by the customer terminal. 

2. A method according to claim 1 , including detecting at the customer terminal a 
network performance parameter which depends on network loading, and varying the 
tariff depending on the network performance parameter. 

10 

3 A method according to claim 2, in which the network is a packet network and 
the network performance parameter is the number of packets lost in transmission 
between a data source and the customer terminal. 

15 4. A method according to claim 1, including detecting a congestion signal at the 
customer terminal and varying the tariff in response to the congestion signal. 

5. A method according to claim 4, including reading a congestion signal at the 
customer terminal from a data packet received at the customer terminal. 

20 

6. A method according to claim 4 or 5, including generating a congestion signal at a 
router in the network in response to the detection of congestion at the router. 

7. A method according to any one of the preceding claims, including making a first 
25 relatively smaller increase in the tariff when congestion is first detected, and making 

at least one further, relatively larger increase, if the congestion persists 

8. A method according to any one of the preceding claims, including programming a 
decision agent at the customer terminal with user-determined price criteria, and 

30 comparing a price calculated using the tariff with the said price criteria. 

9. A method according to any one of the preceding claims, including distributing a 
tariff algorithm via the communications network to a plurality of terminals and 
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calculating at each terminal, using the tariff, a charge for network usage by the 
terminal. 

10. A method according to claim 9, further comprising steps, carried out by the 
network operator, of: 

intermittently sampling traffic between a customer terminal and the network, 
and as part of the sampling recording network loading affecting the customer 
terminal; and 

for the sampled traffic comparing a charge calculated by the customer 
terminal and an expected charge and detecting thereby any discrepancy. 

11. A method according to any one of the preceding claims, in which when the 
customer terminal detects congestion in data transmitted to the customer terminal 
from a data source via the network, the customer terminal returns a congestion 
notification signal to the data source. 

12. A method according to any one of the preceding claims, including at a customer 
terminal, selecting a period of time for which the tariff is to be fixed and paying a 
premium depending on the duration of the said period. 

13. A method of operating a communications network including applying to 
customer terminals a tariff for network usage, varying the tariff with time; at a 
customer terminal, selecting a period of time for which the tariff is to be fixed; and 
paying a premium depending on the duration of the said period. 

14. A communications network including : 

means for detecting network loading locally at a customer terminal; and 
means responsive to the said means for detecting arranged automatically to 
vary a tariff for network usage by the customer terminal. 

15. A customer terminal for use in a communications network, the customer 
terminal including: 
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means for detecting loading of a network to which, in use, the customer 
terminal is connected; 

means responsive to the said means for detecting and arranged automatically 
to vary a tariff for network usage by the customer terminal. 

5 

14. A customer terminal for use in a communications network, the customer 
terminal including one or more processors arranged to carry out the following 
steps in sequence: 

detecting loading of resources in a network to which the customer terminal is 
10 connected; and 

automatically varying in dependence on the detected loading a tariff for 
network usage by the customer terminal. 

15. A method according to any one of claims 1 to 13, in which the tariff is 
15 varied only if the terminal fails to reduce its output in response to detected 

congestion. 
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Fig.9. 
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